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Abstract —In large scale systems such as the Internet, 
replicating data is an essential feature in order to provide 
availability and fault-tolerance. Attiya and Welch proved 
that using strong consistency criteria such as atomicity is 
costly as each operation may need an execution time linear 
with the latency of the communication network. Weaker 
consistency criteria like causal consistency and PRAM con¬ 
sistency do not ensure convergence. The different replicas 
are not guaranteed to converge towards a unique state. 
Eventual consistency guarantees that all replicas eventually 
converge when the participants stop updating. However, it 
fails to fully specify the semantics of the operations on 
shared objects and requires additional non-intuitive and 
error-prone distributed specification techniques. 

This paper introduces and formalizes a new consis¬ 
tency criterion, called update consistency, that requires 
the state of a replicated object to be consistent with a 
linearization of all the updates. In other words, whereas 
atomicity imposes a linearization of all of the operations, 
this criterion imposes this only on updates. Consequently 
some read operations may return out-dated values. Update 
consistency is stronger than eventual consistency, so we 
can replace eventually consistent objects with update con¬ 
sistent ones in any program. Finally, we prove that update 
consistency is universal, in the sense that any object can be 
implemented under this criterion in a distributed system 
where any number of nodes may crash. 
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sistency; Shared Set; Update Consistency; 

I. Introduction 

Reliability of large scale systems is a big challenge 
when building massive distributed applications over 
the Internet. At this scale, data replication is essential 
to ensure availability and fault-tolerance. In a perfect 
world, distributed objects should behave as if there is 
a unique physical shared object that evolves following 
the atomic operations issued by the participant^]. This 
is the aim of strong consistency criteria such as lin- 
earizability and sequential consistency. These criteria 
serialize all the operations so that they look as if they 
happened sequentially, but they are costly to imple¬ 
ment in message-passing systems. If one considers a 
distributed implementation of a shared register, the 

1 We use indifferently participant or process to designate the 
computing entities that invoke the distributed object. 


worst-case response time must be proportional to the 
latency of the network either for the reads or for the 
writes to be sequentially consistent [Tj| and for all 
the operations for linearizability (2j. This generalizes 
to many objects 0. Moreover, the availability of the 
shared object cannot be ensured in asynchronous sys¬ 
tems where more than a minority of the processes of 
a system may crash 0- In large modern distributed 
systems such as Amazon's cloud, partitions do occur 
between data centers, as well as inside data centers 
[41 Moreover, it is economically unacceptable to sac¬ 
rifice availability. The only solution is then to provide 
weaker consistency criteria. Several weak consistency 
criteria have been considered for modeling shared 
memory such as PRAM (T) or causality 0. They expect 
the local histories observed by each process to be 
plausible, regardless of the other processes. However, 
these criteria do not impose that the data eventually 
converges to a consistent state. Eventual consistency 0 
is another weak consistency criterion which requires 
that when all the processes stop updating then all 
replicas eventually converge to the same state. 

This paper follows the long quest of the (a) strongest 
consistency criterion (there may exist several incom¬ 
parable criteria) implementable for different types of 
objects in an asynchronous system where all but one 
process may crash (wait-free systems (6j). A contribu¬ 
tion of this paper consists in proving that weak consis¬ 
tency criteria such as eventual consistency and causal 
consistency cannot be combined is such systems. This 
paper chooses to explore the enforcement of eventual 
consistency. The relevance of eventual consistency has 
been illustrated many times. It is used in practice 
in many large scale applications such as Amazon's 
Dynamo highly available key-value store 0. It has 
been widely studied and many algorithms have been 
proposed to implement eventually consistent shared 
object. Conflict-free replicated data types (CRDT) (8) 
give sufficient conditions on the specification of objects 
so that they can be implemented. More specifically, if 
all the updates made on the object commute or if the 
reachable states of the object form a semi-lattice then 
the object has an eventually consistent implementation 
181 - Unfortunately, many useful objects are not CRDTs. 


The limitations of eventual consistency led to the 
study of stronger criteria such as strong eventual con¬ 
sistency (3. Indeed, eventual consistency requires the 
convergence towards a common state without specifying 
which states are legal. In order to prove the correctness 
of a program, it is necessary to fully specify which 
behaviors are accepted for an object. The meaning of 
an operation often depends on the context in which it 
is executed. The notion of intention is widely used to 
specify collaborative editing flOll . IfTTl . The intention of 
an operation not only depends on the operation and 
the state on which it is done, but also on the intentions 
of the concurrent operations. In another solution [12], 
it is claimed that, it is sufficient to specify what the 
concurrent execution of all pairs of non-commutative 
operations should give (e.g. an error state). This result, 
acceptable for the shared set, cannot be extended to 
other more complicated objects. In this case, any partial 
order of updates can lead to a different result. This 
approach was formalized in [[13], where the concurrent 
specification of an object is defined as a function 
of partially ordered sets of updates to a consistent 
state leading to specifications as complicated as the 
implementations themselves. Moreover, a concurrent 
specification of an object uses the notion of concurrent 
events. In message-passing systems, two events are 
concurrent if they are produced by different processes 
and each process produced its event before it received 
the notification message from the other process. In 
other words, the notion of concurrency depends on 
the implementation of an object not on its specifica¬ 
tion. Consequently, the final user may not know if 
two events are concurrent without explicitly tracking 
the underlying messages. A specification should be 
independent of the system on which it is implemented. 

Contributions of the paper: for not restricting this 
work to a given data structure, this paper first de¬ 
fines a class of data types called UQ-ADT for update- 
query abstract data type. This class encompasses all data 
structures where an operation either modifies the state 
of the object (update) or returns a function on the 
current state of the object (query). This class excludes 
data types such as a stack where the pop operation 
removes the top of the stack and returns it (update 
and query at the same time). However, such operations 
can always be separated into a query and an update 
(lookup_top and delete_top in the case of the stack) 
which is not a problem as, in weak consistency models, 
it is impossible to ensure atomicity anyway. This paper 
has three main contributions. 

• It proves that in a wait-free asynchronous system, 
it is not possible to implement eventual and causal 
consistency for all UQ-ADTs. 


• It introduces update consistency, a new consistency 
criterion stronger than eventual consistency and 
for which the converging state must be consistent 
with a linearization of the updates. 

• Finally, it proves that for any UQ-ADT object with 
a sequential specification there exists an update 
consistent implementation by providing a generic 
construction. 

The remainder of this paper is organized as follows. 
Section [TT] formalizes the notion of consistency crite¬ 
ria and the type of objects we target in this paper. 
Section [III] recalls the definition of (strong) eventual 
consistency. Section [IV] proves that eventual consis¬ 
tency cannot be combined with causal consistency in 
wait-free systems. SectionlVl introduces (strong) update 
consistency and compares it with (strong) eventual 
consistency. Section [Vi] compares, through the exam¬ 
ple of the set, the expressiveness of strong update 
consistency and strong eventual consistency. Section 
IVIII presents a generic construction for any UQ-ADT 
object with a sequential specification. Finally, Section 
IVIIII concludes the paper. 

II. Abstract Data Types and Consistency 
Criteria 

Before introducing the new consistency criterion, 
this section formalizes the notion of object and how a 
consistency criterion is defined. In distributed systems, 
sharing objects is a way to abstract message-passing 
communication between processes. The abstract type 
of these objects has a sequential specification, defined 
in this paper by a transition system that character¬ 
izes the sequential histories allowed for this object. 
However, shared objects are implemented in a dis¬ 
tributed system using replication and the events of 
the distributed history generated by the execution of a 
distributed program is a partial order [114] . The consis¬ 
tency criterion makes the link between the sequential 
specification of an object and a distributed execution 
that invokes it. This is done by characterizing the 
partially ordered histories of the distributed program 
that are acceptable. The formalization used in this 
paper is explained with more details in (.15]. 

An abstract data type is specified using a transition 
system very close to Mealy machines |16] except that 
infinite transition systems are allowed as many objects 
have an unbounded specification. As stated in the 
Introduction, this paper focuses on "update-query" 
objects. On the one hand, the updates have a side- 
effect that usually affects the state of the object (hence 
all processes), but return no value. They correspond 
to transitions between abstract states in the transition 
system. On the other hand, the queries are read-only 
operations. They produce an output that depends on 




the state of the object. Consequently, the input alphabet 
of the transition system is separated into two classes 
of operations (updates and queries). 

Definition 1 (Update-query abstract data type). An 
update-query abstract data type (UQ-ADT) is a tuple 

O = (U, Q z ,Qo, S, s 0 , T, G) such that: 

• 17 is a countable set of update operations; 

• Qi and Q a are countable sets called input and 
output alphabets; Q = Qi x Q a is the set of 
query operations. A query operation ( qi,q 0 ) £ Q 
is denoted qi/q 0 (query q, returns value q 0 ). 

• S' is a countable set of states-, 

• so £ S is the initial state; 

• T : S x U —r S is the transition function; 

• G : S x Qi —>• Q 0 is the output function. 

A sequential history is a sequence of operations. An 
infinite sequence of operations (wi)igN £ (17 U Q) u is 
recognized by O if there exists an infinite sequence of 
states (sj)*>i £ S 1 ^ (note that so is the initial state) 
such that for all * £ N, T(si,wt) = Sj+i if Wi £ 17 or 
Si = s l+ i and G(si, qi) = q a if Wi = qi/q 0 £ Q- The set of 
all infinite sequences recognized by O and their finite 
prefixes is denoted by L(0). Said differently, 7(0) is 
the set of all the sequential histories allowed for O. 

Along the paper, replicated sets are used as the key 
example. Three kinds of operations are possible: two 
update operation by element, namely insertion (I) and 
deletion (D) and a query operation read (R) that returns 
the values that belong to the set. Let Val be the support 
of the replicated set (it contains the values that can be 
inserted/deleted). At the beginning, the set is empty 
and when an element is inserted, it becomes present 
until it is deleted. More formally, it corresponds to the 
UQ-ADT given in Example [l] 

Example 1 (Specification of the set). Let Val be a 
countable set, called support. The set object Sy a i is the 
UQ-ADT (U, Qi, Q a , S, 0, T, G) with: 

• U = {I(u),D(u) : v £ Val}; 

• Qi = {R}, and Q 0 = S = V <00 (Val) contain all the 
finite subsets of Val; 

• for all s £ S and v £ Val, G(s, R) = s, 

T(s, I(u)) = s U {z;} and T(s, D(z;)) = s \ {u}. 

The set U of updates is the set of all insertions and 
deletions of any value of Val. The set of queries Qi 
contains a unique operation R, a read operation with 
no parameter. A read operation may return any value 
in Q 0 , the set of all finite subsets of Val. The set S of 
the possible states is the same as the set of possible 
returned values Q 0 as the read query returns the 
content of the set object. I(v) (resp. D(v)) with v £ Val 
denotes an insertion (resp. a deletion) operation of the 


value v into the set object. R/s denotes a read operation 
that returns the set s representing the content of the set. 

During an execution, the participants invoke an 
object instance of an abstract data type using the asso¬ 
ciated operations (queries and updates). This execution 
produces a set of partially ordered events labelled by 
the operations of the abstract data type. This repre¬ 
sentation of a distributed history is generic enough 
to model a large number of distributed systems. For 
example, in the case of communicating sequential pro¬ 
cesses, an event a precedes an event b in the program 
order if they are executed by the same process in that 
sequential order. It is also possible to model more 
complex modern systems in which new threads are 
created and destroyed dynamically, or peer-to-peer 
systems where peers may join and leave. 

Definition 2 (Distributed History). A distributed his¬ 
tory is a tuple H = (U, Q, E, A, >->■): 

• U and Q are disjoint countable sets of update and 
query operations, and all queries q £ Q are in the 
form q = qjq 0 ; 

• E is a countable set of events; 

• A : E —> U UQ is a labelling function; 

• i-^c E x E is a partial order called program order, 
such that for all e £ E, {e' £ E : e' i->- e} is finite. 

Let H = (U, Q, E, A, >->■) be a history. The sets Uh = 
{e £ E : A(e) £ 17} and Q H = {e £ E : A(e) £ Q} 
denote its sets of update and query events respectively. 
We also define some projections on the histories. The 
first one allows to withdraw some events: for F C E, 
Hp = (17, Q, F, A|f, i->- n(F x F)) is the history that 
contains only the events of F. The second one allows 
to substitute the order relation: if —» is a partial order 
that respects the definition of a program order ((->), 
i7” > = (U, Q, E, A, — > fl {E x E)) is the history in which 
the events are ordered by —x Note that the projections 
commute, which allows the notation H]f. 

Definition 3 (Linearizations). Let 77 = (U,Q,E,A,\-^) 
be a distributed history. A linearization of 77 corre¬ 
sponds to a sequential history that contains the same 
events as 77 in an order consistent with the program 
order. More precisely, it is a word A(eo)... A(e„)... 
such that {eo,..., e n ,...} = E and for all i and j, if 
i < j, 6j yfr d. We denote by lin(77) the set of all 
linearizations of 77. 

Definition 4 (Consistency criterion). A consistency 
criterion C characterizes which histories are allowed 
for a given data type. It is a function C that associates 
with any UQ-ADT O, a set of distributed histories 
C(O). A shared object (instance of an UQ-ADT O) is 
C-consistent if all the histories it allows are in C(0). 


III. Eventual Consistency 

In this section, we recall the definitions of eventual 
consistency (4j and strong eventual consistency 13 - 
Fig, [l] illustrates these two consistency criteria on small 
examples. In the remaining of this article, we consider 
an UQ-ADT O = (U. Q,. Q„. S, so, T. G) and a history 
H=(U,Q,E, A,-*). 

Eventual consistency: eventual consistency requires 
that, if all the participants stop updating, all the repli¬ 
cas eventually converge to the same state. In other 
word, H is eventually consistent if it contains an infi¬ 
nite number of updates (i.e. the participants never stop 
writing) or if there exists a state (the consistent state) 
compatible with all but a finite number of queries. 

Definition 5 (Eventual consistency). A history H is 
eventually consistent (EC) if Uh is infinite or there 
exists a state s E S such that the set of queries 
that return non consistent values while in the state s, 

{qi/qo 6 Qh '■ G(s, qi) ± q a }, is finite. 

All the histories presented in Fig. |l] are eventu¬ 
ally consistent. The executions represent two processes 
sharing a set of integers. In Fig. [la] the first process 
inserts value 1 and then reads twice the set and gets 
respectively {2} and {1}; afterwards, it executes an 
infinity of read operations that return the empty set 
(<u in superscript denotes the operation is executed an 
infinity of times). In the meantime, the second process 
inserts a 2 then reads the set an infinity of times. It gets 
respectively {1} and {2} the two first times, and empty 
set an infinity of times. Both processes converge to the 
same state (0), so the history is eventually consistent. 
However, before converging, the processes can read 
anything a finite but unbounded number of times. 

Strong eventual consistency: strong eventual consis¬ 
tency requires that two replicas of the same object con¬ 
verge as soon as they have received the same updates. 
The problem with that definition is that the notions 
of replica and message reception are inherent to the 
implementation, and are hidden from the programmer 
that uses the object, so they should not be used in 
its specification. A visibility relation is introduced to 
model the notion of message delivery. This relation is 
not an order since it is not required to be transitive. 

Definition 6 (Strong eventual consistency). A history 
H is strong eventually consistent (SEC) if there exists 
an acyclic and reflexive relation —(called visibility 
relation) that contains i-t and such that: 

• Eventual delivery: when an update is viewed by 
a replica, it is eventually viewed by all replicas, so 
there can be at most a finite number of operations 
that do not view it: 

Mu g Uh, {e &E,u^e} is finite; 


• Growth: if an event has been viewed once by a 
process, it will remain visible forever: 

Ve, e', e" e£,(e^e' Ae'u e") =► (e ^4 e"); 

• Strong convergence: if two query operations view 
the same past of updates V, they can be issued in 
the same state s: MV C Uh, 3s e S,Mqi/q 0 E Qh, 

V = {uGU h :u qi/q Q } => G(s,qi) = q Q . 

The history of Fig. [la] is not strong eventually con¬ 
sistent because the 1(1) must be visible by all the 
queries of the first process (by reflexivity and growth), 
so there are only two possible sets of visible updates 
((1(1)} and{I(l), 1(2)}) for these events, but the queries 
are done in three different states ({1}, {2} and 0); 
consequently, at least two of these queries see the same 
set of updates and thus need to return the same value. 
Fig. O on the contrary, is strong eventually consistent: 
the replicas that see (1(1)} are in state 0 and those that 
see {1(1), 1(2)} are in state {1,2}. 

IV. Pipelined Convergence 

A straightforward way to strengthen eventual con¬ 
sistency is to compose it with another consistency 
criterion that imposes restrictions on the values that 
can be returned by a read operation. Causality is often 
cited as a possible candidate to play this role flOl . As 
causal consistency is well formalized only for memory, 
we will instead consider Pipelined Random Access 
Memory (PRAM) [1J, a weaker consistency criterion. 
As the name suggests, PRAM was initially defined for 
memory. However, it can be easily extended to all UQ- 
ADTs. Let's call this new consistency criterion pipelined 
consistency (PC). In a pipelined consistent computation, 
each process must have a consistent view of its local 
history with all the updates of the computation. More 
formally, it corresponds to Def.0 Pipelined consistency 
is local to each process, as different processes can see 
concurrent updates in a different order. 

Definition 7. A history H is pipelined consistent (PC) 
if, for all maximal chains (i.e. sets of totally ordered 
events) p of H, lin (Hjj h \j p ) H L(0) ± 0. 

Pipelined consistency can be implemented at a very 
low cost in wait-free systems. Indeed, it only requires 
FIFO reception. However, it does not imply conver¬ 
gence. For example, the history given in Figure [2] is 
pipelined consistent but not eventually consistent. In 
this history, two processes p\ and p-, share a set of 
integers. Process pi first inserts 1 and then 3 in the set 
and then reads the set forever. Meanwhile, process P 2 
inserts 2, deletes 3 and reads the set forever. The words 
wi and w -2 are correct linearizations for both processes, 
with regard to Definition [7] so the history is pipelined 
consistent, but after stabilization, p 2 sees the element 
3 whereas p± does not. 


1(1) R/{2} R/{1} R/0" 


1(1) D(2) R/ {1,2} a 

• I—> • |-* • 


1(1) R/0 R/{1,2} u 


1(2) R/{1} R/{2} R/0" 

(a) EC but not SEC nor UC 


• I—> • |-> • 

1(2) D(l) R/{1,2 r 
(b) SEC but not UC 


R/i'sr 


1 ( 2 ) 

(c) SEC and UC but not SUC 


1(1) R/{1} 1(2) R/{l,2} ta 

• | - > • | - > • | - > • 

R/* 2} R/{L 2} u 

(d) SUC but not PC 


Figure 1: Four histories for an instance of S-;\ (cf. example 1), with different consistency criteria. The arrows 
represent the program order, and an event labeled uj is repeated an infinite number of times. 
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R/{1,2,3} R/{1,2}“ 
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|- > o ' 1 |-> #■? 

R/{2} R/{1,2} R/{1,2,3}“ 


TO! = 1(1)-1(3)-R/{1,3}-I(2)-R/{1,2,3}-D(3)-R/{1,2}“ 
w 2 = 1(2) ■ D(3) • R/{2} • 1(1) ■ R/{1,2} ■ 1(3) ■ R/{1,2,3}" 


V. Update Consistency 

In this section, we introduce two new consistency 
criteria: update consistency and strong update consis- 
tencjQ, and we compare them to eventual consistency 
and strong eventual consistency. Fig. [T] illustrates these 
four consistency criteria on four small examples. 


Figure 2: PC but not EC 

Proposition 1 (Implementation). Pipelined convergence, 
that imposes both pipelined consistency and eventual con¬ 
sistency, cannot be implemented in a ivait-free system. 

Proof: We consider the same program as in Figure 
13 and we suppose the shared set is pipelined conver¬ 
gent. By the same argument as developed in (2|, it is 
not possible to prevent the processes from not seeing 
each other's first update at their first reads. Indeed, 
if pi did not receive any message from process p 2 , it 
is impossible for pi to make the difference between 
the case where p 2 crashed before sending any message 
and the case where all its messages were delayed. To 
achieve availability, p\ must compute the return value 
based solely on its local knowledge, so it returns {1,3}. 
Similarly, p 2 returns {2}. To circumvent this impossi¬ 
bility, it is necessary to make synchrony assumption 
on the system (e.g. bounds on transmission delays) or 
to assume the correctness of a majority of processes. 

If the first read of p\ returns {1,3}, as the set is 
pipelined consistent, there must exist a linearization 
for pi that contains all the updates, R/{1,3} and 
an infinity of queries. As 2 ^ {1,3}, the possible 
linearizations are defined by the ca-regular language 
1(1) *1(3) ■ R/{1,3} + T(2) • R/{1,2,3}* -D(3) -R/{1,2}“, so 
any history must contain an infinity of events labelled 
R/{ 1,2}"’. Similarly, if p 2 starts by reading {2}, it 
will eventually read {1, 2, 3} an infinity of times. This 
implies that pipelined convergence cannot be provided 
in wait-free systems. ■ 

Consequently causal consistency, that is stronger 
than pipelined consistency, cannot be satisfied together 
with eventual consistency in a wait-free system. 


Update consistency: eventual consistency and 
strong eventual consistency are not interested in defin¬ 
ing the states that are reached during the histories (the 
same updates have to lead to the same state whatever 
is the state). They do not depend on the sequential 
specification of the object, so they give very little 
constraints on the histories. For example, an implemen¬ 
tation that ignores all the updates is strong eventually 
consistent, as all the queries return the initial state. 
In update consistency, we impose the existence of a 
total order on the updates, that contains the program 
order and that leads to the consistent state according 
to the abstract data type. Another equivalent way to 
approach update consistency is that, if the number 
of updates is finite, it is possible to remove a finite 
number of queries such that the history is sequentially 
consistent. 

Definition 8 (Update consistency). A history H is 
update consistent (UC) if Uh is infinite or if there 
exists a finite set of queries Q' C Q n such that 
lin ( H e \q> ) (~l L(0) ± 0. 

The history of Fig. [Tc] is update consistent because 
the sequence of operations I(1)I(2) is a possible ex¬ 
planation for the state {1,2}. The history of Fig. Ilbl is 
not update consistent because any linearization of the 
updates would position a deletion as the last event. 
Only three consistent states are actually possible: state 
0, e.g. for the linearization 1(1) • 1(2) • D(l) • D(2), state 
{1} for the linearization 1(2) -D(l) -1(1) D(2) and state 
{2} for the linearization 1(1) • D(2) • 1(2) • D(l). Update 
consistency is incomparable with strong eventual con¬ 
sistency. 

2 These consistency criteria were previously presented as a brief 
announcement in DISC 2014 Il7l . 
















Strong update consistency: strong update consis¬ 
tency is a strengthening of both update consistency and 
strong eventual consistency. The relationship between 
update consistency and strong update consistency is 
analogous to the relation between eventual consistency 
and strong eventual consistency. 

Definition 9 (Strong update consistency). A history H 
is strong update consistent (SUC) if there exists (1) an 
acyclic and reflexive relation that contains i—> and 
(2) a total order < that contains —such that: 

• Eventual delivery: 

Vit £ Ur, {e £ E,u e} is finite; 

« Growth: 

Ve, e', e" £ E, (e e'Ae'4 e"^ => e"^j ; 

• Strong sequential convergence: A query views an 
update if this update precedes it according to 
Each query is the result of the ordered execution, 
according to <, of the updates it views: 

V? £ Qh, lin (^v{q)u{q}) ^ ^ ® 

where V{q) = {u £ Ur '■ u q}. 

Fig. Ildl shows an example of strong update con¬ 
sistent history: nothing prevents the second process 
from seeing the insertion of 2 before that of 1. Strong 
eventual consistency and update consistency does not 
imply strong update consistency: in the history of Fig. 
Hcl after executing event 1(1), the only three possible 
update linearizations are 1(1), 1(1) • 1(2) and 1(2) ■ 1(1) 
and none of them can lead to the state 0 according 
to the sequential specification of a set object. So the 
history of Fig. [13 is not strong update consistent, while 
it is update consistent and strong eventually consistent. 

Proposition 2 (Comparison of consistency criteria). If 
a history H is update consistent, then it is eventually 
consistent. If H is strong update consistent, then it is both 
strong eventually consistent and update consistent. 

Proof: Suppose H is update consistent. If H con¬ 
tains an infinite number of updates, then it is even¬ 
tually consistent. Otherwise, there exists a finite set 
Q' C Qh and a word w £ lin fl L(0). As 

the number of updates is finite, there is a finite prefix 
v of w that contains them all. v £ L(0), so it labels 
a path between so and a state s in the UQ-ADT. All 
the queries that are in w but not in v return the same 
state s, and the number of queries in Q' and v is finite. 
Hence, H is eventually consistent. 

Suppose H is strong update consis¬ 
tent with a finite number of updates. 
Q' = U uGUh {q £ Qh , q < u} is finite, and lin {Er \ Q') 
contains only one word that is also contained into 
L(0). Obviously, H is update consistent 


Now, suppose H is strong update consistent. Strong 
update consistency respects both eventual delivery 
and growth properties. Let V C Ur. As the rela¬ 
tion < is a total order, there is a unique word w in 
lin 1-1 fdO). Let us denote s the state obtained 

after the execution of w. For all q £ Q H such that V = 
{u £ Ur : u q], lin (-fff 9U{g} J n L (°) = { w ‘ A (?)}' 
so q = qi/q 0 with G(s,qf) = q 0 . Consequently, H is 
strong eventually consistent. ■ 

VI. Expressiveness of Update Consistency: a 
Case Study 

The set is one of the most studied eventually con¬ 
sistent data structures. Different types of sets have 
been proposed as extensions to CRDTs to implement 
eventually consistent sets even though the insert and 
delete operations do not commute. The simplest set 
is the Grow-Only Set (G-Set) 0 , in which it is only 
possible to insert elements. As the insertion of two 
elements commute, G-Set is a CRDT. Using two G-Set, 
a white list for inserted elements and a black list for 
the deleted ones, it is possible to build a Two-Phases 
Set (2P-Set, a.k.a. U-Set, for Unique Set) fl8l . in which 
it is possible to insert and remove elements, but never 
insert again an element that has already been deleted. 
Other implementations such as C-Set Ifl9l and PN-Set, 
add counters on the elements to determine if they 
should be present or not. The Observe-Remove Set 
(OR-Set) (9)/ 112011 is the best documented algorithm for 
the set. It is very close to the 2P-Set in its principles, but 
each insertion is timestamped with a unique identifier, 
and the deletion only black-lists the identifiers that 
it observes. It guaranties that, if an insertion and 
a deletion of the same element are concurrent, the 
insertion will win and the element will be added 
to the set. Finally, the last-writer-wins element set 
(LWW-element-Set) 0 attaches a timestamp to each 
element to decide which operation should win in case 
of conflict. All these sets, and the eventually consistent 
objects in general, have a different behavior when they 
are used in distributed programs. 

The above mentioned implementations are even¬ 
tually consistent. However, as eventual consistency 
does not impose a semantic link between updates and 
queries, it is hazardous to say anything on the confor¬ 
mance to the specification of the object. Burckhardt et 
al. fT3l propose to specify the semantics of a query by a 
function on its concurrent history, called visibility, that 
corresponds to the visibility relation in strong eventual 
consistency, and a linearization of this history, called 
arbitration. In comparison, sequential specifications are 
restricted to the arbitration relation. It implies that 


fewer update consistent objects than eventually consis¬ 
tent objects can be specified. Although the variety of 
objects with a distributed specification seems to be a 
chance that compensates the lower level of abstraction 
it allows, an important bias must be taken into account: 
from the point of view of the user, the visibility of an 
operation is not an a priori property of the system, but 
an a posteriori way to explain what happened. If one 
only focuses on the final state, an update consistent ob¬ 
ject is appropriate to be used instead of an eventually 
consistent object, since the final state is the same as if 
no operations were concurrent. 

By adding further constraints on the histories, con¬ 
current specifications strengthen the consistency cri¬ 
teria. Even if strong update consistency is stronger 
than strong eventual consistency, we cannot say in 
general that a strong update consistent object can al¬ 
ways be used instead of its strong eventually consistent 
counterpart. We claim that this is true in practice for 
reasonable objects, and we prove this in the case of 
the Insert-wins set (the concurrent specification of the 
OR-set). The arbitration relation is not used for the 
OR-set, and the visibility relation has already been 
defined for strong eventual consistency. The concurrent 
specification only adds one more constraint on this 
relation: an element is present in the set if and only 
if it was inserted and is not yet deleted. 

Definition 10 (Strong eventual consistency for the 
Insert-wins set). A history H is strong eventu¬ 
ally consistent for the Insert-wins set on a sup¬ 
port Val if it is strong eventually consistent for 
the set Svai and the visibility relation veri¬ 

fies the following additional property. For all x G 
Val and q G Qh, with A (q) = R/s, x G s <t> 
G vis(q,I(x)),Vu' G vis(q,D(x)),u u'^j , where 

for all o G U, vis(q, o) = {u G Uh ■ u q A A(u) = o}. 

The OR-Set implementation of a set is not update 
consistent. The history on Fig. [lb] is not update consis¬ 
tent, as the last operation must be a deletion. However, 
if the updates made by a process are not viewed by 
the other process before it makes its own updates, 
the insertions will win and the OR-set will converge 
to {1,2}. On the contrary, a strong update consistent 
implementation of a set can always be used instead of 
an Insert-wins set, as it only forbids more histories. 

Proposition 3 (Comparison with Insert-wins set). Let 
H = (U, Q, E, A, !->•) be a history that is strong update 
consistent for Sy a i ■ Then H is strong eventually consistent 
for the Insert-wins set. 


Proof: Suppose H is strong update consistent for 
S Yai . We define the new relation ,W > such that for all 
e, e' G E, e ,W > e' if one of the following conditions 
holds: 


VIS / 

• e —> e ; 

• e and e' are two updates on the same element and 

e < e'; 

• e! is a query, and there is an update e" such that 
e^e" and e" e'. 


The relation is acyclic because it is included in 
<, its growth and eventual delivery properties are 
ensured by the fact that it contains ■—>. Moreover, 
no two updates for the same element are concurrent 
according to ■ and the last updates are also the last 
for the < relation, consequently H is strong eventually 
consistent for the Insert-wins set. ■ 


This result implies that an OR-set can always be 
replaced by an update consistent set, because the guar¬ 
anties it ensures are weaker than those of the update 
consistent set. It does not mean that the OR-set is 
worthless. It can be seen as a cache consistent set El 
that, in some cases may have a better space complexity 
than update consistency. 


VII. Generic Construction of Strong Update 
Consistent Objects 

In this section, we give a generic construction of 
strong update consistent objects in crash-prone asyn¬ 
chronous message-passing systems. This construction 
is not the most efficient ever as it is intended to 
work for any UQ-ADT object in order to prove the 
universality of update consistency. For a specific object 
an ad hoc implementation on a specific system may be 
more suitable. 


A. System Model 

We consider a message-passing system composed of 
finite set of sequential processes that may fail by halting. 
A faulty process simply stops operating. A process 
that does not crash during an execution is correct. We 
make no assumption on the number of failures that 
can occur during an execution. Processes communi¬ 
cate by exchanging messages using a communication 
network complete and reliable. A message sent by a 
correct process to another correct process is eventually 
received. The system is asynchronous; there is no 
bound on the relative speed of processes nor on the 
message transfer delays. In such a situation a process 
cannot wait for the participation of any a priori known 
number of processes as they can fail. Consequently, 
when an operation on a replicated object is invoked 


Algorithm 1: a generic UQ-ADT (code for pf) 

i object (U, Qi , Q 0 , S , s 0 , T, G) 

2 

var clock, £ N £- 0; 

3 

var update, c (N x N x U) <- 0; 

4 

fun update (u £ U) 

5 


clock, <- clock, + 1; 

6 


broadcast message (clock;, i, u); 

7 

end 

8 

on receive message (cl £ N,j £ N, U £ Q) 

9 


clock, £- max(clock, ,cl); 

10 


update, <- update; u {(cl, j, u)}; 

11 

end 

12 

fun query (q £ Qi) £ Q a 

13 


clock, -f- clock, + 1; 

14 


Vclf Stclt@2 G S i — 50/ 

15 


for (cl,j, u) £ update, sorted on (cl,j) do 

16 


state,: ■£- Testate*, u); 

17 


end 

18 


return G(state,, q); 

19 

end 

20 end 



locally at some process, it needs to be completed based 
solely on the local knowledge of the process. We call 
this kind of systems wait-free asynchronous message¬ 
passing system. 

We model executions as histories made up of the se¬ 
quences of events generated by the different processes. 
As we focus on shared objects and their implemen¬ 
tation, only two kinds of actions are considered: the 
operations on shared objects, that are seen as events in 
the distributed history, and message receptions. 

B. A universal implementation 

Now, we prove that strong update consistency is 
universal, in the sense that every UQ-ADT has a 
strong update consistent implementation in a wait- 
free asynchronous system. Algorithm [l] presents an 
implementation of a generic UQ-ADT. The principle 
is to build a total order on the updates on which all 
the participants agree, and then to rewrite the history 
a posteriori so that every replica of the object eventu¬ 
ally reaches the state corresponding to the common 
sequential history. Any strategy to build the total order 
on the updates would work. In Algorithm [lj this order 
is built from a Lamport's clock [14] that contains the 
happened-before precedence relation. Process order is 
hence respected. A logical Lamport's clock is a pre¬ 
total order as some events may be associated with the 
same logical time. In order to have a total order, the 
events are timestamped with a pair composed of the 
logical time and the id of the process that produced it 


(process ids are assumed unique and totally ordered). 
The algorithm actions performed by a process pi are 
atomic and totally ordered by an order i—The union 
of these orders for all processes is the program order 
i— y. 

At the application level, a history is composed of 
update and query operations. In order to allow only 
strong update consistent histories. Algorithm [l] pro¬ 
poses a procedure update () and a function query(). 
A history H is allowed by the algorithm if update(u) 
is called each time a process performs an update u, 
and query(qi) is called and returns q 0 when the event 
<7i/ q 0 appears in the history. The code of Algorithm |l] 
is given for process pt. Each process p, manages its 
view clocki of the logical clock and a list updatesi of 
all timestamped update events process pi is aware of. 
The list updatesi contains triplets ( cl,j,u ) where u is 
an update event and (cl, j) the associated timestamp. 
This list is sorted according to the timestamps of the 
updates: (cl,j) < (cl',j ') if (cl < cl') or (cl = cl’ and 

j < /)• 

The algorithm timestamps all events (updates and 
queries). When an update is issued locally, process 
Pi informs all the other processes by reliably broad¬ 
casting a message to all other processes (including 
itself). Hence, all processes will eventually be aware 
of all updates. When a message(cl,j,u) is received. 
Pi updates its clock and inserts the event to the list 
updatesi . When a query is issued, the function queryQ 
replays locally the whole list of update events pi is 
aware of starting from the initial state then it executes 
the query on the state it obtains. 

Whenever an operation is issued, its is completed 
without waiting for any other process. This corre¬ 
sponds to wait-free executions in shared memory dis¬ 
tributed systems and implies fault-tolerance. 

Proposition 4 (Strong update consistency). All histories 
allowed by Algorithm^ are strong update consistent. 

Proof: Let H = (U,Q,E, A, i—>-) be a distributed 
history allowed by Algorithm |T| Let e, e' £ Eh be 
two operations invoked by processes pi and p,/, on 
the states (update, clock) and (update', clock'), 
respectively. We pose: 

• e e' if e £ Uh and yv received the message 
sent during the execution of e before it starts 
executing e', or e £ Qh and e d e', As the mes¬ 
sages are received instantaneously by the sender, 
contains i—h It is growing because the set of 
messages received by a process is growing with 
time. 









• e < e' if c < c' or c = d and i < %'. This 
lexical order is total because two operations on 
the same process have a different clock. Moreover 
it contains because when p,/ received the 
message sent by e, it executed line 9 and when 
it executed e', it executed line 5, so d > c + 1. 
Moreover, the history of e contains at most cxn+i 
events, where n is the number of processes, so it 
is finite. 

Let q G Qh and E q = {u G Uh ■ u —)■ q}. Lines 
15 to 18 build an explicit sequential execution, that is 
in lin u{q}) by definition of < and in L(0) by 
definition of O. ■ 

C. Complexity 

Algorithm Q] is very efficient in terms of network 
communication. A unique message is broadcast for 
each update and each message only contains the infor¬ 
mation to identify the update and a timestamp com¬ 
posed of two integer values, that only grow logarithmi¬ 
cally with the number of processes and the number of 
operations. Moreover, this algorithm is wait-free and 
its execution does not depend on the latency of the 
network. 

This algorithm re-executes all past updates each time 
a new query is issued. In an effective implementation, 
a process can keep intermediate states. These interme¬ 
diate states are re-computed only if very late message 
arrive. The algorithm does not look space efficient also 
as the whole history must be kept in order to rebuild a 
sequential history. Because data space is cheap and fast 
nowadays, compared to bandwidth, many applications 
can afford this complexity and would keep this infor¬ 
mation anyway. For example, banks keep track of all 
the operations made on an account for years for legal 
reasons. In databases systems, it is usual to record all 
the events in log files. Moreover, asynchrony is used 
as a convenient abstraction for systems in which trans¬ 
mission delays are actually bounded, but the bound is 
too large to be used in practice. This means that after 
some time old messages can be garbage collected. 

The proposed algorithm is a theoretical work whose 
goal is to prove that any update-query object has a 
strong update consistent implementation. This gener- 
icity prevents an effective implementation that may 
take benefit from the nature and the specificity of 
the actual object. The best example of this are pure 
CRDTs like the counter and the grow-only set. If all the 
update operations commute in the sequential specifi¬ 
cation, all linearizations would lead to the same state 
so a naive implementation, that applies the updates 
on a replica as soon as the notification is received, 
achieves update consistency. In [22], Karsenty and 


Algorithm 2: the shared memory (code for 

i object UC_mem(X, V, vq ) 

2 

var clock, G N t— 0; 

3 

var mem,; G mem(I, (N 2 x V ), (0,0, v 0 )); 

4 

fun write (XGl,VGb) 

5 


clock, g- clock, + 1; 

6 


broadcast msg (clock,, i,X,v); 

7 

end 

8 

on receive msg (cl G N, j G N, x G X, v G V) 

9 


clock, g— max(clock,,cl); 

10 


var (cl',j',v') G N 2 x V <- mem,.read(x); 

11 


if (Cl', j') < (cl, j) then 

12 


| mem,.write(x, (cl,j, v)) 

13 


end 

14 

end 

15 

fun read (x G X) G V 

16 


var (cl,j, v) G N 2 x V G- mem,.read(x); 

17 


return V; 

18 

end 

19 end 



Beaudouin-Lafon propose an algorithm to implement 
objects such that each update operation u contains 
an undo u -1 such that for all s, T(T(s,u),u^ 1 ) = s. 
This algorithm is very close to ours as it builds the 
convergent state from a linearization of the updates 
stored by each replica. They use the undo operations 
to position newly known updates at their correct place, 
which saves computation time. As it is a very frequent 
example in distributed systems, we now focus on the 
shared memory object. 

Algorithm |2] shows an update consistent implemen¬ 
tation of the shared memory object. A shared memory 
offers a set X of registers that contain values taken 
from a set V. The query operation read(x), where 
x € X, returns the last value v G V written by 
the update operation write(x, v), or the initial value 
vo € V if x was never written. Algorithm |2] orders the 
updates exactly like Algorithm|T| As the old values can 
never be read again, it is not necessary to store them 
forever, so the algorithm only keeps in memory the last 
known value of each register and its timestamp in a 
local memory mem,, implemented with an associative 
array. When a process receives a notification for a 
write, it updates its local state if the value is newer 
that the current one, and the read operations just 
return the current value. This implementation only 
needs constant computation time for both the reads 
and the writes, and the complexity in memory only 
grows logarithmically with time and the number of 
participants. 









VIII. Conclusion 

This paper proposes a new consistency criterion, 
update consistency, that is stronger than eventual con¬ 
sistency and weaker than sequential consistency Our 
approach formalizes the intuitive notions of sequential 
specification for an abstract data type and distributed 
history. This formalization first allowed to prove that 
eventual consistency when associated with causal con¬ 
sistency or PRAM consistency can no more be imple¬ 
mented in an asynchronous distributed system where 
all but one process may crash. 

This paper formalizes the new consistency criterion 
and proves that (1) it is strictly stronger than eventual 
consistency and (2) that it is universal in the sense 
that allowed any update consistent object can be im¬ 
plemented in wait-free systems. The latter has been 
proved through a generic construction that implement 
all considered data types. 
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